In an IP Multimedia System (IMS) architecture, Session Initiation Protocol (SIP) applications can be invoked from a feature sequencer to perform a service. Many times multiple applications are chained in an application sequence together to perform an array of different services for the caller and/or callee. Depending on the type of service, a SIP application could be implemented as a SIP proxy, a SIP user agent, or a back-to-back user agent (B2BUA). These logical network elements provide different functions.
Generally, a SIP proxy would be used to route a call to a specific destination. For example, an application that interprets the “To”, “From” or some custom headers and routes a call accordingly, could be implemented as a SIP proxy.
Alternatively, an application that manages multiple call legs and the state of those call legs must be implemented as a B2BUA, which is more robust and flexible than a simple SIP proxy. Using the previous example, if the application provided music on hold to the caller while it attempted a call to a destination, it would be implemented as a B2BUA.
B2BUA are more common in Enterprise IMS deployments due to the complex contact center and enterprise unified communication scenarios. For example, a contact center may want a caller to hear special announcements while waiting for the next available agent. After the announcements are provided, another application may be invoked to ask the caller if they would participate in survey after the call. This is an example of chaining two applications into a sequence.
Because B2BUAs have to manage the state of multiple call legs, they are often more complex to program as well as being more processor intensive than SIP proxies or user agents. Empirical data suggests that B2BUAs consume roughly four times more processor time than proxies. When multiple B2BUA applications are deployed to the same physical server, the effect can be quite constraining
Consider the following comparison:
A single proxy in a single CPU can support 120 call-per-second then—3 chained proxies in a single CPU can support 40 calls-per-second.
A single B2BUA on a single CPU can support 30 calls-per-second then—3 chained B2BUAs can support 10 calls-per-second.
When an application sequence requires multiple B2BUAs to be invoked, the processing delay for the call be become quite noticeable. Specifically, if three B2BUAs are chained in a single application sequence, each of the three B2BUA applications in the sequence would have to implement a similar application framework for managing multiple call legs as well as a similar state machine for dealing with state transitions. This can become quite cumbersome and can restrict the implementation of highly scalable solutions.